"System Resource Exceeded" for simple select query in Access 2013

Using Access 2013 32-bit on a Windows Server 2008 R2 Enterprise. This computer has 8 GB of RAM.

I am getting:

"System Resource Exceeded errors in two different databases for simple queries like:

SELECT FROM .... GROUP BY ...

UPDATE... SET ... WHERE ...

I compacted the databases several times, no result. One database size is approx 1 GB, the other one is approx. 600 MB.

I didn't have any problems in Office 2010 so I had to revert to this version.

Please advise.

Regards,

M.R.




  • Edited by MR1000 Wednesday, May 22, 2013 3:11 PM
May 22nd, 2013 3:02pm

I have seen this problem when running Access on a computer with multiple processors. Try changing the Processor Affinity for the MSACCESS process in Task Manager down to just one processor, and see if that improves performance.
Free Windows Admin Tool Kit Click here and download it now
April 24th, 2015 11:46am

  Mark, thanks for the suggestion.  Unfortunately this is not possible for us as it is running on RDP servers with 20 people on the each server. I think 'bad things' would happen if everyone was running it on the same processor.  Unless maybe we came up with some script to randomly pick a processor when the person starts the program.  I think you may be on to something though I have seen strange errors in other software resolve when I set the processor affinity.

 With over a hundred people using the application all day long we only get the error about two or three times a week so it is pretty hard to track down.

   Greg

April 24th, 2015 12:01pm

Hi Greg. I too am running Access on an RDP server. Checking Task Manager, I can see many copies of MSACCESS running in the process list, from all users on the server. We typically have 40-60 users on that server. I am only changing the Processor Affinity for MY copy, and only when I run into this problem. Restarting Access daily, I always get back to multi-processor mode soon thereafter.

As this problem only seems to happen on very large Access table updates, and as there are only three of us performing those kind of updates, we have good control on who might want to change the affinity setting to solve this problem. However, I understand that in other environments this might not be a good solution. In my case, we have 16 processors on the server, so I always take #1, my co-worker here in the US always takes #2, etc. This works for us, and I am only describing it here in case it works for someone else.

The big question in my mind is what multi-threading methods are employed by Microsoft for Access that would cause this problem for very large datasets. Processing time for an update query on, say, 2 million records is massively improved by going down to 1 processor. The problem is easily reproduced, and so far I have not seen it in Excel even when working with very large worksheets. Also have not seen it in MS SQL. It is just happening in Access.

Free Windows Admin Tool Kit Click here and download it now
April 24th, 2015 5:39pm

  It does seem like maybe there is a multi-threading bug lurking in there somewhere.  Interestingly, this error on our systems seems to have nothing to do with large datasets.  Fairly small queries will cause it and there seems to be no pattern to where it will pop up.   The only pattern I was able to find is we have 6 RDP servers, a bank of three configured with one set of software and three with another set of software.  Both are identical OS and access runtime versions, but the error only ever happens on the first bank of servers.   Maybe some program installed on the one bank of servers is triggering the error somehow.

  Greg

April 24th, 2015 5:50pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics